-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility rework #59
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy with the changes on the XLCore side to go forward once the submodule changes are in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall happy with the changes to detect distribution, just have some small questions/thoughts about it
src/XIVLauncher.Core/Program.cs
Outdated
@@ -44,7 +44,9 @@ class Program | |||
|
|||
private static readonly Vector3 clearColor = new(0.1f, 0.1f, 0.1f); | |||
private static bool showImGuiDemoWindow = true; | |||
|
|||
public static string Distro { get; private set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be an idea to make this an enum so we're more aware of the valid values for it, could then just assign an attribute of its url value so we cna download the wine version from it using that attribute name.
Honestly not sure about moving game fixes to xlcore wholesale, maybe adding a parameter to it for the currently hosted version by SE would be cleaner, ultimately something like Then it is still possible to add in dynamic version information fetching on the xlcore side later. |
The way gamefixes is setup here doesn't seem like too much of a problem to me since it allows passing it in from either side & it makes it easier to adjust fixes that aren't going to apply to the main repo anyway |
I agree with that and that was probably the main motivation behind this change... However xlcore is mostly a frontend for XIVLauncher.Common and this change muddies the waters a bit (there is for example a special exception in the game repair logic for these video files, you could add validation there in the future as well, but this is gonna become difficult to maintain by splitting parts of the codebase for convenience and not architecture) Ultimately this is a similar argument to #10 |
I'm totally happy to keep things in XIVLauncher.Common but it would be nice to have an easier path to getting changes made in XIVLauncher.Common.Unix as right now any functional change we want made has to go through it. |
Yeah XIVLauncher.Common has become a bit of a bottleneck for functional changes... Having said that (slightly off-topic again) I think the correct video URL can be extracted from SEs sparkle feed, so this won't really need any adjustments in the future. |
So should I revert this? We could also have GameApplyFixes to either accept an array/list as a contstructor arg (as I already did), or add a function to add fixes one at a time. Then you could just do something like
|
Personally I am not a huge fan of adding game fixes from the xlcore side (as in xlcore holds their implementation), but that is a matter of taste. |
Okay, reverted the video fix move. |
src/XIVLauncher.Core/Distro.cs
Outdated
|
||
namespace XIVLauncher.Core; | ||
|
||
public enum WinePackage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels a bit weird having the wine package enum inside the Distro file..
This seems to be completely unused anyways
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually used in the WineManager to determine which wine package to download. I've renamed to DistroPackage now.
src/XIVLauncher.Core/Distro.cs
Outdated
|
||
public static bool IsFlatpak { get; private set; } | ||
|
||
public static void GetInfo() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is called GetInfo()
and returns nothing, which is not very intuitive to use, especially with the static properties next to it.
All of this also only makes sense on a target system that needs wine (and even then only on Linux).
Each csproj has WIN32
, OSX
and LINUX
constants defined, which could be used here.
Also not sure if this needs to be a top-level file here at all, there is also https://github.com/goatcorp/FFXIVQuickLauncher/blob/410cc9ed0624c37879b747ad69ba6e61c18c6f0f/src/XIVLauncher.Common/Platform.cs#L7
src/XIVLauncher.Core/DxvkManager.cs
Outdated
throw new ArgumentOutOfRangeException(); | ||
} | ||
|
||
var settings = new DxvkRunner(folder, url, Program.storage.Root.FullName, env, isDxvk); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I understand the concept of a DxvkRunner that doesn't run DXVK, or even the concept of runner at all, since it is more of a install/setup step before launching the game.
Also if the DxvkRunner isn't holding DXVK configuration it is setting up WineD3D and/or MangoHUD.
src/XIVLauncher.Core/Program.cs
Outdated
@@ -75,6 +75,7 @@ private static void SetupLogging(string[] args) | |||
|
|||
Log.Information("========================================================"); | |||
Log.Information("Starting a session(v{Version} - {Hash})", AppUtil.GetAssemblyVersion(), AppUtil.GetGitHash()); | |||
Log.Information("Running on {DistroName}, wine package set to {DistroPackage}", Distro.Name, Distro.Package.ToString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again this only makes sense on Linux, the XIVLauncher.Common Platform enum is probably a better fit here.
src/XIVLauncher.Core/Program.cs
Outdated
var wine = WineManager.Initialize(); | ||
var dxvk = DxvkManager.Initialize(); | ||
var wineoverride = "msquic=,mscoree=n,b;"; | ||
var wineenv = new Dictionary<string, string>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wine Environment variables are set a bit all over the place, some here, some in the WineManager and some inside CompatibilityTools.
Would be nice setting everything that must be set, be set in CompatibilityTools, but still allow passing in extra env vars (but ideally only from 1 place)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Now it's all in CompatibilityTools
Program.CompatibilityTools.AddRegistryKey("HKEY_CURRENT_USER\\Software\\Wine\\Direct3D", "renderer", "gl"); | ||
} | ||
|
||
Program.CompatibilityTools.RunInPrefix($"winecfg /v {winver}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
@@ -12,7 +12,7 @@ public override void Draw() | |||
{ | |||
ImGui.TextUnformatted("Generic Information"); | |||
ImGui.Separator(); | |||
ImGui.TextUnformatted($"Operating System: {Environment.OSVersion}"); | |||
ImGui.TextUnformatted($"Operating System: {Distro.Name} - {Environment.OSVersion}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is should ideally be a XIVLauncher.Common Platform
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might go through and fix all of this at some point; do the full initialization of OS info in the Distro object (maybe rename it), and then change all the Environment.OSVersion.Platform checks to refer to the XIVLauncher.Common Platform value set in said Distro object. But I think there's enough going on atm. For now, I've added in some checks to make sure the Linux-specific stuff only shows up if it's actually on Linux.
return null; | ||
}, | ||
}, | ||
new SettingsEntry<string>("MangoHud Custom Path", "Set a custom path for MangoHud config file.", () => Program.Config.DxvkMangoCustom, s => Program.Config.DxvkMangoCustom = s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a Linux-only config option, and even then only useful when MangoHUD is actually installed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the moment, there's a function that looks for specific paths where Linux installs MangoHud, and it won't let you save your selection if it doesn't find it (it will show an error). I think the whole DXVK tab is really linux only. Only the Disabled/WineD3D setting would work on MacOS atm (if that), and only if you manually provided a wine release. Maybe there's DXVK for freebsd? Not sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DXVK is a PE only binary that translates Windows dx calls into Windows Vulkan calls (simplified), so it will run on any platform that supports the necessary Windows Vulkan feature level which is Wine on Linux, FreeBSD, macOS (if the native unix implementation has all needed extensions) and even on Windows itself (where it is sometimes used to provide better frame pacing, or just in general better performance that the native Windows dx driver)
src/XIVLauncher.Core/DxvkManager.cs
Outdated
var dxvkfolder = Path.Combine(rootfolder, "compatibilitytool", "dxvk"); | ||
var async = (Program.Config.DxvkAsyncEnabled ?? true) ? "1" : "0"; | ||
var framerate = Program.Config.DxvkFrameRate ?? 0; | ||
var env = new Dictionary<string, string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of a design question (similar to the wine env vars), should these env vars be set here or inside the "runner", which gets passed a log file path and a dxvk config file
src/XIVLauncher.Core/DxvkManager.cs
Outdated
env.Add("DXVK_HUD","0"); | ||
env.Add("MANGOHUD","1"); | ||
|
||
if (mangoHudConfig is null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a lot of MagoHUD handling going on here, maybe better to factor that out into its own class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the hud stuff to its own class. There's also now a function that checks for mangohud being installed, and will set hudtype to none if somehow the user ends up manually setting mangohud in the .ini file without having it installed. DxvkSettingsTab already will not let you save settings in that case.
* Changed names of classes to WineSettings and DxvkSettings * Removed a bunch of unused variables * Moved WINEDLLOVERRIDES * Update submodule
* Also split out Hud settings from Dxvk * Renamed some vars and funcs for better clarity * Removed some duplicate functions * Hopefully made a bit more platform independant.
* Added button for explorer with WineD3D * Changed SetWin7 to two buttons to set windows type quickly
So, in no particular order:
|
* Make Hud options a bit more clear * Add warning for MangoHud+ReShade+Dalamud
Closing and replacing with #64 |
This replaces the Dxvk Settings rework - #17.
Here's the compatibilitytools rework I mentioned a few weeks ago. This moves most of the bits that will change over to the XL.Core side, such as specific versions of wine or dxvk, where they will be stored, and what environment variables need to be set for each one.
I also moved the MacVideoFix over to XL.Core. I figure individual implementations of fixes can be done on the XL.Core side, and then passed to GameFixApply object.
Depends on goatcorp/FFXIVQuickLauncher#1348
And here's a link to a flatpak build if you want to test:
https://github.com/rankynbass/XIVLauncher.Core/releases/edit/compatrework-v1
Install with
flatpak install xivlauncher-rework.flatpak
, run withflatpak run dev.goats.testing.xivlauncher
.